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ABSTRACT 



An information frame of a new format transmitted according 
to a radio link protocol (RLP), and a device and method for 
transmitting and receiving the information frame in a mobile, 
communication system. The information frame is comprised 
of a plurality of con secutive multiplex fram e s each having a 
given length/The multiplex frames each are 'comprised of a 
header and a succeeding RLP frame, and the RLP frame 
includes transmission data . At least one of the multiplex 
frames is comprised of a plurality o f sub -multiplex frames, 
and each sub-multiplex frame is comprised of a header 
' including an RLP , service identifier field and a length indi - 
cation field for indicating a length of the transmission data . 
and a data block associated to the succeeding RLP fram eT 

8 Claims, 11 Drawing Sheets 
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APPARATUS AND METHOD FOR schemes different from that of FIG. 1. However, they have 

EXCHANGING VARIABLE-LENGTH DATA a common feature that the link protocol packets with the 

ACCORDING TO RADIO LINK PROTOCOL upper service data are tra nsmitted over the radio physical 

IN MOBILE COMMUNICATION SYSTEM channel through the RLP. 

5 The RLP Type-3 specification generates only the RLP 
frame having a size proper to fill a physical channel frame 

PRIORITY of 9 6 j^gp or l9 2 Kbps for the current Rate Set 1, or the 

This application claims priority to an application entitled RLP frame havin e a size P ro P er t0 mi a Physical channel 

r "Apparatus and Method for Exchanging Variable-Length n frame of UA Kb P s or 2 s - 8 Kb P s for the Rate Set 2 - 

\ Data accordin g to Ra d io Link Protocol in Mobile Commu- 10 Therefore, when the physical channel operates at the higher 

/ "nfcSon System" tiled in the Korean Industrial Property rate of 153 - 6 ^P 5 or 2304 there * used a method for 

V Office on May 10, 1999 and assigned Ser. No. 99-1791 1, the fiUin § several RLP frames in one Physical channel frame. If 

contents of which are hereby incorporated by reference. ihQ P h y sical channel su PP orts the rate of over 153 6 or 230 ' 4 

Kbps which is the maximum rate supported in the RLP 

BACKGROUND OF THE INVENTION 15 Type-3 specification, for example, if the physical channel 

supports the rates of 307.2 Kbps, 460.8 Kbps, 614,4 Kbps 

1. Field of the Invention and 10 36.8 Kbps, more RLP frames can be filled in one 
The present invention relates generally to a CDMA (Code physical channel frame. However, as compared with the 

Division Multiple Access) mobi le communication system, method for filling one physical channel with one large -sized 

and in particular, to a device andmethod for transmitting and 20 rlp frame, this method causes an increase in a burden on 
receiving data according to a radio link protocol (RLP) used" the frame header and unusable parts of the frame, thereby 

tor effective data transmission in radio enviro nments, decreasing the frame efficiency. Therefore, to transmit the 

2. Description of the Related Art RLP frame having the size larger than the current RLP 
In general, a CDMA mobile communication system has ^P^ 3 frame > a new method is squired. 

developed from the IS -95 standard which mainly provides a „ T „ „ , 4 MT „ mTT ^ Tk „ „. v ™ rtkT 

^voice servi ce into the CDMA-2000 standard which provides SUMMARY OF THE INVENTION 

"Trligh'-speed^data service as well as the voice service. The it is, therefore, an object of the present invention to 

CDMA-2000 standard can provide ^hi gh-quality voice provide a device and method for transmitting an RLP frame 

service, moving picture service and Internet search service; 3Q 0 f various lengths by octet-baseTsequenc m g white trans- 

FIG. 1 shows an exemplary packet data service defined by Hutting data according to an RLP in a morJile communic a- 

the CDMA-2000 standard. In FIG. 1, a mobile station (MS) lion system.'" ' 

includes a terminal equipment (TE) and a mobile termina- it is another object of the present invention to provide a 

tion (MT). A base station is represented by BS/MSC (Base device and method for transmitting an information frame (or 

Station/Mobile Switching Center), and an interworking 3S physical frame) having various frame sizes and structures 

function block for connecting the BS/MSC to a data network with more data by proposing effective multiplexing/ 

(e.g., Internet), represented by IWF. The IWF block is a demultiplexing control to support the RLP frame of various 

device for converting protocols from one to another, when lengths while transmitting data according to an RLP in a 

different protocols are used. In FIG. 1, the upper service (or mobile communication system 

Web service) processors of the mobile station and the IWF ^ To achieye ^ above obj thefe ^ ided ^ Mof _ 

block exchange data through a network protoco (or Internet matioQ frflme of a new format transmitted accordj to a 

protocol (IP) processor and a ^ protocol or point-to- ^ ^ q{ (RLp) m& fl ^ ^ ^ for 

point protocol ^ processor, inat is trie data assembled transmittmg and receiving the information frame in a mobile 

by the upper service processors is final y transmitted to he «g^ n ^fo n syst em . LtoUl on frame is comprised . 

bwer ayets in the form of the link protocol packet, and the 4 5 of a plurality of c tnircutlv^^ 

lower layers transmit the data using a proper protocol. - given leng th. The multiplex frames eac h are comprised of T 

FIG. 1 shows an example where an EIA-232 controller is header and a succeeding RLP frame, and the RLP frame 

used between the TE and the MT. The link protocol packets includes transmission data . . At least one of the multiplex 

transmitted to the MT through the EIA-232 controller are frames is comprised of a plurality of sub-multiplex frames/ 

distributed to radio link protocol (RLP) frames through the st r an d each sub-multiplex f r ame is comprised of a header 

RLP according to the present invention. Such generated RLP including an RLP service identifier field and a leng th indi- 

frame is transmitted over a physical channel connected cation field for indicating a length of the transmission dataT 

according to the IS-2000 standard which is the CDMA-2000 an d a data block associated to the succeeding RLP frame. 

standard. The RLP packets received at the base station over ' - 

the connected physical channel are restored back to the link 55 BRIEF DESCRIPTION OF THE DRAWINGS 
protocol packets and the restored packets are transmitted to 

the IWF block through the relay layer. In general, interfacing ^ above and other ob J ects > features and advantages of 

between the base station and the IWF block is performed the P resent i nvent i° n w iU become more apparent from the 

according to the IS-658 standard. The IWF block reads data following detailed description when taken in conjunction 

from the link protocol packets and transmits the data to the 60 Wlth the accompanying drawings in which: 

network protocol processor, and the data is finally transmit- FIG. 1 is a diagram illustrating a general CDMA com- 

ted to the upper service processor. municalion system for performing a packet data service; 

Although a description has been made of a process for FIG, 2 is a diagram illustrating a device for transmitting 

transmitting data from the mobile station to the base station , and receiving data according to the RLP, to which the 

the process for transmitting th e data fro m the base station to 65 present invention is applicable; 

_ the mobile station can be periormeq similarly. To provi de FIG. 3 is a diagram illustrating a data transmitter accord - 

various services, the CDMA-2000 standard supports various ing to the present invention; 
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FIG. 4 is a diagram illustrating a data receiver according buffers 122, 124, 222 and 224 and the link protocol proces- 

to the present invention; sors 110 and 210. For the current CDMA-2000 packet 

FIGS. 5A to 5D are diagrams illustrating a format of the service, it is possible to use a controller other than the 

frames generated by the data transmitter of FIG. 2; EIA-232 controller and the 1S-658 controller. For this 

TTtr-c cr> a- mi * *• * < f*u 5 reason, the controllers are not shown in FIG. 2. 

FIGS. 6A to 6C are diagrams illustrating a format of the CTr , \ . . ... . 

mT/T n ,;„jT..^v v tt -a *I j • . . i FIG. 3 shows a data transmitter according to the present 

LTU (Logical Transmission Unit) generated according to the :„.,_♦• n r . . „ OT „ 6 f 

\ • t - invention. Referring to FIG. 3, the RLP processor 130 for 

present invention; transmitting the RLP frame includes a RLP controller 131, 

FIG. 7 is a diagram illustrating a format of the data blocks a n L__V(S) register 132, and a forward resequencing buffer 

generated according to the present invention; J(J 133. The RLP controller 131 generates an RLP frame by 

FIG. 8 is a diagram illustrating a format of the RLP frames receiving data from the transmission data buffer 122 and 

generated according to the present invention; transmits a data block with the generated RLP frame to the 

FIG. 9 is a flow diagram illustrating a procedure for multiplexing/demultiplexing controller 140. The forward 

transmitting a fundamental channel according to the present resequencing buffer 133 is a memory device for storing data 

invention; 15 for resequencing. The L_V(S) register 132 stores, when 

FIG. 10 is a flow diagram illustrating a procedure for transmitting the data on a byte unit basis, a sequence number 

receiving a fundamental channel according to the present °f each bvte - 

invention; FIG. 4 shows a data receiver according to the present 

FIG. 11 is a flow diagram illustrating a procedure for invention. Referring to FIG. 4, the RLP processor 130 for 

transmitting a supplemental channel according to the present 20 receiving the RLP frame includes the RLP controller 131, an 

invention* and E re g ister 134 > an L__V(N) register 135, an L_V(R) register 

FIG. 12 is a flow diagram illustrating a procedure for 136 > a JJ^? 137 and a ^arrange buffer 138. The RLP 

receiving a supplemental channel according to the present C0 ° r ° Uer * 31 the J? /" me /° m 

invention multiplexing/demultiplexing controller 140 and examines 

25 whether the data is received in order. If the data is received 

DETAILED DESCRIPTION OF THE ™ order, the RLP controller 131 stores the data in the 

PREFERRED EMBODIMENT receiving data buffer 124. Otherwise, the RLP controller 131 

A _ , , , , . . .„ , stores the data in the rearrange buffer 138, and then records 

A preferred embodiment of the present invention will be the rtion ( iod) to be ted for retransmission in me 

desenbedherem below w,th reference to the accompanying NAK (Non Acknowledge) list 137, to transmit the period 

drawings. In the following description, well-known func- stored in thc NAK Usl m whcn transmilti J Qext 

tions or constructions are not described in detail since they control frame 



would obscure the invention in unnecessary detail. 



The E register 134 records the number of damaged (or 



r FIG. 2 shows a structure of a mobile communication bad) data blocks When the mll i t ip lexing / dernultiplexing 
) system for transmitting and receiving data according 3S 140 notifies the damaged data blocks, the RLP 
I KLF to which the present invention is applica ble. controller 131 records this value in the E register 134 to use 
V Referring to FIG. 2, physical layer processors 150 and it when reestablishment is required. The RLP controller 131 
250 connect a physical channel between the mobile station judges that new data is received, when a data byte having a 
and the base station according to the IS-2000 specification, sequence number larger than or equal to the value of the 
transmit the RLP frames provided from associated RLP 40 L_V(R) register 136 is received. Otherwise, when a data 
processors 130 and 230 to the other party's physical layer byte having a sequence number smaller than the value of the 
over the connected physical channel, and transmit the RLP L_V(R) register 136 and larger than or equal to the value of 
frames received over the physical channel to the RLP the L_V(N) register 135, the RLP controller 131 judges that 
processors 130 and 230. retransmitted data is received. The L_V(N) register 135 
Multiplexing/demultiplexing controllers 140 and 240 45 stores the sequence number of the damaged data byte (or 
have the multiplexing function of attaching at the head of the receive -failed data byte) out of the data to be received. That 
RLP frames the destination and size information for the RLP is, the L__V(N) register 135 stores the sequence number of 
frames to be transmitted to the physical layer processors 150 the data byte to be received next out of the consecutively 
and 250, and transmitting the RLP frames to the physical received data bytes. The L_V(R) register 136 stores the 
layer processors 150 and 250. Further, the multiplexing/ 50 sequence number of the new data byte to be received next, 
demultiplexing controllers 140 and 240 have the demulti- Operation of generating an RLP frame of variable length 
plexing function of detecting the destination and size of the and tra remitting/receiving the generated RLP frame accord- 
received RLP frames, and then transmitting the detection ing to the present invention can be broadly divided into 
results to the upper RLP processors 130 and 230. operation performed by the multiplexing/demultiplexing 
Transmission and reception data buffers 122, 124, 222 and 55 controllers 140 and 240, and operation performed by the 
224 are memory devices for storing data that the EIA-232 RLP processors 130 and 230. Since the multiplexing/ 
controller of FIG. 1 or the IS -658 controller has received demultiplexing controllers 140 and 240 have the same 
from link protocol (PPP) processors 110 and 210. The data operation and the RLP processors 130 and 230 also have the 
buffers 122 and 222 segment in sequence the stored packets same operation, a description of the operation according to 
by the required size at the request of the RLP processors 130 60 the present invention will be limited to the multiplexing/ 
and 230. The data buffers 124 and 224 store in sequence the demultiplexing controller 140 and the RLP processor 130, 
data provided from the RLP processors 130 and 230. The for simplicity. Herein, the general transmitting and receiving 
stored data is transmitted to the PPP processor or the IWF operation performed by the multiplexing/demultiplexing 
block by the EIA-232 controller or the IS-658 controller. controller shown in FIGS. 2 to 4 will be first described. Next, 
The EIA-232 controller or the IS-658 controller operates 65 a description will be made of the transmitting and receiving 
according to the EIA-232 specification and the IS-658 operation performed by the multiplexing/demultiplexing 
specification, and performs data exchange between the data controller according to an embodiment of the present inven- 



03/12/2004, EAST Version: 1.4.1 



US 6,665,313 Bl 

5 6 

tion. The transmitting and receiving operation performed by ing such a service between the mobile station and the base 

the multiplexing/demultiplexing controller can be per- station and connecting the logical channel for the service to 

formed over the fundamental channel (FCH) or the supple- the physical channel is available with the signaling message 

mental channel (SCH). Next, a description will be made of and the signaling procedure, defined by the IS -2000 speci- 

the data transmitting and receiving operation performed by 5 fication, 

the RLP controller shown in FIGS. 3 and 4 according to the ^ multiplexing/demultiplexing controller 140 of the 

present invention. transmission side receives the data block of a proper length 

A. Tx/Rx Operation of General Multiplexing/ (see FIG. 5A) from the service according to a priority order, 

Demultiplexing Controller upon deciding to transmit the data block for the services 

1. Tx Operation of Multiple xing/Demul Up lexing Control- 10 corresponding to the physical channel to which the logical 

* er channel is presently connected. The multiplexing/ y, > 

It is possible to simultaneously transmit not only the demultiplexing controller 140 makes a multiplex frame 

packet data but also various other information including the - Mux?DV inchlde thc data block addinfi thc serv i cc identifier 

volce data ' over a Presently connected "physical channel. ' and the length indication fiel d (see FIG. 5B 1 so that it is 

Therefore, providing data to be transmitted to the 15 ; p0SS1Dlc to L ovo_ser vke-lor transmitting the data block 

multiplexing/demultiplexing controller will be referred to as " received fromTnfn^^g/dcmulUplcxing controller of 
^service" . Further, a transmission unit that the multiplexing/" the receiving side when receiving the data block from thF * 
demultiplexing controller 140 and the physical layer pro- ' service . The mult iplex frame MuxPDU can include several 

cessor 150 exchange with each other will be referred to. as . data blocks and signalinZm essages provided from seveT aT 

^information bits" or "physical frame", and a transmission ^ services^ The informl tSTbi ts include one or several 

unit that the upper service block, including the RLP proces- MuxPDUsTand can further include a CkC (Cyclic Red"\n> 

sor 130, and the multiplexing/demultiplexing controller 140 dancv Codel for checking errors "every one or several 

exchange with each other will be referred to as "RLP frame" - MuxPDUs. When the CRC for checking errors every several 

^QL"data blQCk"- ' MuxPDUs is added, one CRC and a period of the informa- 

The multiplexi ng/demultiplexing cont roller 140 of the ^ Uon blts protected by the CRC are ca]le d a "logical trans- 

transmission side should generate the information bits to be mission unit (LTU) W When the CRCs are inserted such that 

transmitted to the physical layer processor 150 and transmit the in f ormation bits to be transmitted to the physical layer 

the generated information bits every set time (e.g., 20 ms). are segm ented into several periods and error checking is 

That is, the multiplexing/demultiplexing controller 140 performed on every segmented period, it is said that "logical 

should generate information bits to be filled in a payload of 30 transmission unit is used". Here, each period of the seg- 

the frame to be transmitted over the physical channel with men ted information bits is referred to as "logical transmis- 

respect to all the presently connected physical channels and sion and tne remaining period of the logical transmis- 

transmit the generated information bits. The multiplexing/ sion ^ exc i ud i ng the CRC, protected by the CRC, will be 

demultiplexing controller 140 transmits the following referred to as « a payload of the logical transmission unit", 

X) ^lu^when transmitting the generated information bits to 35 ( FIG 5C y This logical transmission unit becomes a base 

I The physical channel. unit for determining whether the physical frame is correctly 

I SDU : This field is filled with the information bits to be received at the multiplexing/demultiplexing controller ofthe 

I actually transmitted. If there is no information bit to be ' receiving sid e. If the logic transmission unit is not used, a 

\ transmitted, this field is filled with a ^null value previ - " bas j c unit for determining whether the physical frame is 

\ ously determined between the multiplexing/ 40 correctly received becomes the information bits. 

\ demultiplexing controller and the physical layer. The multiplexing/demultiplexing controller 140 of the 

1 FRAME SIZE : This field is filled with the size infor- transmission side previously knows a possible transmission 

I mation of the physical channel frame in which the rate and a size of the information bits with respect to the 

/ information bits are filled. When the SDU field is filled physical channel to be presently transmitted, and knows 

( with the null value, this field value is ignored in the 45 whether the logic transmission unit is used or not, the size 

I physical layer. of the logic transmission unit if it is used, ^nd a CRC 

/ FRAME_RATE: This field indicates a transmission rate j ^ eneration method . Such a configuration is used to deter- 

/ of the physical channel frame in which the information mine the size of the information bits generated by the 

I bits are filled. When the SDU field is filled with the null multiplexing/demultiplexing controller 140 according to the 

V value, this field value is ignored in the physical chan- so present condition of the physical channel provided from the 

\^ nel. physical layer and determine a method for generating the 

When the multiplexing/demultiplexing controller 140 of logic transmission unit, within a limit previously determined 

the transmission side transmits the above field values to the between the mobile station and the base station, 

physical layer processor 150, the physical layer processor When there is no more data block to be transmitted, the 

150 processes the provided values in the designated coding 55 multiplexing/demultiplexing controller 140 uses the Mux- 

and demodulation method and then transmits the processed PDU to which is attache d_a specific service identifier pre- 

results to the receiving side. viously appointed with the multiplexing/demultiplexin g 

To generate the payload or information bits of a logical controller of the receiving side, or uses a regular bit pattern 

transmission unit to be transmitted to the physical channel, previously appointed with the multipleYin g/demnltipleYinp 

the multiplexing/demultiplexing controller 140 of the trans- 60 controller of the receiving side, in order to fill the remaining 

mission side uses a data block to be transmitted in the period of the information bits. Herein, the MuxPDU to 

services corresponding to the physical channel to which the which the specific service identifier is attached will be 

logical channel is presently connected. The service corre- referred to as "fill MuxPDU" and the regular bit pattern will 

sponding to the physical channel to which the logical be referred t o a s "fill bit pattern". 

channel is connected, refers to a service which can transmit 65 When there is no si g naling message or data block to be y 

its data block to the physical channel which will transmit the transmitted, the multiplexing/demultiplexing controller 140 Q 

presently generated information bits. A process for connect- can transmit the null value to the physical channel with \ 
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SDU, or transmit a regular bit pattern previously appointed FRAME_QUALITY that a damaged frame is received, the 

with the multiplexing/demultiplexing controller of the multiplexing/demultiplexing controller 140 of the receiving 

receiving side to the physical channel as the information side determines whether the logic transmission unit is used 

bits. Herein, the regular bit pattern will be referred to as for the received frame, based on the configuration and the 

"null, traffic". 5 information provided from the physical layer processor 150 

When use of the logic transmission unit is determined, the Q £ we receiving side, 

multiplexing/demultiplexing controller 140 of the transmis- If ^ logic transmission unit is used, the multiplexing/ 

S '?.u fu \l f l lf V""™' 00 u !" 1 demultiplexing controller 140 of the receiving side deter- 

withtheM"^™^ mines a , e to Qf ^ i ogic transmission unit, a CRC 

Knerl CRC ^he n nf , Z ' 10 ^ ™« thC ™ mb " ° f lo S ic Emission 

then generates a CRC for the payload of each generated t ™T u - i • /j n- t • 7 n * a* 

logic trar^missiarSmT Hie multiplexing/demultiplexing < multiplexmg/demultiplexing controller 140sepa- 

controller 140 of the transmission side repeats the above rates logic transmission units from the received infor- 

process as many times as the number of the necessary logic matlon blts ™ man y 35 thc number of iht lo & c transmission 

transmission units, fills the information bits with the gener- units> 

ated logic transmission units and then fills the remaining 15 Whcn the assigned physical channel transmits the 

period with '0' before transmission to the physical channel. received information bits, the multiplexing/demultiplexing 

When it is determined not to use the logic transmission controller 140 of the receiving side determines whether the 

unit, the multiplexing/demultiplexing controller 140 of the received information bits are damaged or not, depending on 

transmission side fills the information bits with the Mux- the FRAME„QUALITY transmitted from the physical 

PDU including the data block, fills the remaining period 20 channel. It the received information bits are damaged and 

with the fill MuxPDU or the fill bit pattern, and then the received information bits are segmented into several 

transmits the generated information bits to the physical logic transmission units, the multiplexing/demultiplexing 

channel. controller 140 a nalyzes the CRC of each logic transmission 

2. Rx Operation of Multiplexing/Demultiplexing Control- again, separated in the above process, to determine 

-^ cr 25 whether there exist error-free logic transmission units. 

The physical layer processor 150 of the receiving side, „ If mere exists ^ erroneous logic transmission unit, the 

shown m FIG. 2, analyzes a received signal using a desig- multiplexing/demultiplexing controller 140 informs all the 
nateddecodmg aqd demoduU^io^thod T aqd transmi tet^e. ser vices corresponding to the physic al channel to which the 
Formation bits fflkd in the received physical frame , teufae n ^ ch£mnel ^ connected that a damaged data block is 

multiplexing/demultiplexing controller 140 of th e receiving 3Q with ect tQ ^ erTODeous lo ^ c transmission 

^The physical layer controller 150 transmitslhe follow- ^ M m { ^ multip i exin ^ demu i tiplexing 

ing information, when transmitting the anafeed information ^ 14Q ^ Q informg ^ maximum y & of me correspond . 

bits to the muluplexing/demultiplexing controller 140. ing SGTy[cQ data block in whicfa ^ damaged ^ trang _ 

- SDU : This field is filled with the information bits to be mission ^ ^ 5e mcluded , with resp ect to the respective 

actually transmitted. If there is no received information 35 services 

bit or a damaged frame is received, this field is filled when the received i nformatio D bits are dama ged and thf 

with a null value previously determined between the revived information bits have no CRC for checking an error 

multiplexing/demultiplexing controller 140 and the every one or several MuxPDU. the multiplexing / 

£~ physical layer processor 150. demultiplexing controller 140 of the receiving side informs 

>IKAME— QUALITY : This field indicates whether or not 4u "all the services corresponding to the physical channel to 

/ the received frame is a valid frame. ' which the logical channel is connected that a damageddata 

FRAME_SIZE : This field is filled with the size infor- block is received. AtHhis point, the multiplexing/ 

mation of the received physical channel frame. This demultiplexing controller 140 also informs the maximum 

field value is determined according to a transmission length of the corresponding service data block in which the 

rate of the received physical channel frame. 45 damaged logic transmission unit can be included, with 

FRAME_RATE : This field is filled with the transmission respect to the respective services. 

rate of the received physical channel frame. When the error-free logic transmission unit or information 

The multiplexing/demultiplexing controller 140 of the bit is received, the multiplexing/demultiplexing controller 

receiving side previously knows a transmission rate and a 140 of the receiving side separates error-free MuxPDUs, 

size of the information bits with respect to the presently 50 which are not the fill bit pattern, from the information bits, 

received physical channel, and also knows whether the logic If the separated MuxPDU is not the null traffic or the fill 

transmission unit is used or not, the size of the logic MuxPDU, the multiplexing/demultiplexing controller 140 

transmission unit if it is used, and a CRC generation method. transmits the data block included in the MuxPDU and a 

Such a configuration can be determined according to the length of the data block to the service designated by the 

above information provided from the physical channel pro- 55 service identifier of the MuxPDU. 

cessor 150 within a limit previously appointed between the If the error-free logic transmission or information bit is 

mobile station and the base station. received and there is a service which failed to receive the 

If the multiplexing/demultiplexing controller 150 of the data block out of the services in which the logical channel 

receiving side fills the SDU with jhe null value , j udging that corresponds to the physical channel, the multiplexing/ 

no physical channel frame is received, and informs the 60 demultiplexing controller 140 of the receiving side can 

l*'kAMh (J UALlTY that a valid frame is received, then the inform that a null data block is received. 

multiplexing/demultiplexing controller 140 of the receiving " B. Tx/Rx Operation of Multiplexing/Demultiplexing Con- 

side informs alLthe services corresponding to the physical troller According to an Embodiment of the Invention 

channel to which the logical channel is connected that no A transmitting/receiving operation of the multiplexing/ 

~f ra me is r ece i ve d . 65 demultiplexing controller 140 according to the present 

When the physical layer processor 150 of the receiving invention will be more apparent from the following detailed 

side does not fill the SDU with the null value or informs the description. The IS-2000 standard specifies several dedi- 
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cated traffic channels such as a fundamental channel, a 
supplemental channel and a dedicated control channel. 
Therefore, the transmitting and receiving operation of the 
multiplexing/demultiplexing controller 140 according to the 
invention may be separately described for a case where it is 
applied to the fundamental channel and another case where 
it is applied to the supplemental channel. Further, the 
operation may be separately described for the case where the 
logic transmission unit is used and the other case where the 
logic transmission unit is not used. Here, the case where the 
logic transmission unit is used corresponds to a case where 
data is coded using a convolution code- befo re-lxansmittinp. 
and receiving the_data, and the case where,th e_logic-trans- 
mission unit is not use corresponds to a case where the data 
is coded using a turbo code be fore transmitting and receiv- 
ing the data. " " " 



TABLE 1 



Information Bit Number of IS-2000 Fundamental Channel (Rate Set 1) 
Transmission Rate Information Bit Number 



9600 bps 
4800 bps 
2700 bps 
1S00 bps 



172 bits 
80 bits 
40 bits 
16 bits 



TABLE 2 



Information Bit Number of IS-2000 Fundamental Channel (Rate Set 2) 
Transmission Rate Information Bit Number 



14400 bps 
7200 bps 
3600 bps 
1800 bps 



267 bits 
125 bits 
55 bits 
21 bits 



TABLE 3 



I nformation Bit Number of IS-2000 Supplemental Channel (Rate Set 1) 
Transmission Rate Information Bit Number 



9600 bps 


172 bits 


19200 bps 


360 bits 


3S400 bps 


744 bits 


76800 bps 


1512 bits 


153600 bps 


304S bits 


307200 bps 


6120 bits 


614400 bps 


12264 bits 



20 



1. Information Bit Number of Fundamental channel and 
Supplemental Channel 

Prior to describing an operation according to an embodi- 
ment of the present invention, the information bit number of 
the fundamental channel and the supplemental channel 
specified by the IS-2000 standard are first shown in Tables 
1 to 4. Tables 1 and 2 show the information bit number of 25 
the fundamental channel specified by the IS-2000 standard, 
and Tables 3 and 4 show the information bit number of the 
supplemental channel. Tables 1 and 3 show the information 
bit number of Rate Set 1 based on the transmission rate of 
9600 bps, and Tables 2 and 4 show the information bit 
number of Rate Set 2 based on the transmission rate of 
14400 bps. 



30 



10 



TABLE 4 



Information Bit Number of IS-2000 Supplemental Channel fRate Set 21 
Transmission Rate Information Bit Number 



14400 bps 


267 bits 


28800 bps 


552 bits 


57600 bps 


1128 bits 


115200 bps 


2280 bits 


230400 bps 


4584 bits 


460800 bps 


9192 bits 


1036800 bps 


20712 bits 



It should be noted that Tables 1 to 4 have not shown all 
15 the information bit sizes specified by the IS-2000 standard. 
When the LTU (Logic Transmission Unit) is used corre- 
sponding to the information bit numbers having a sufficient 
number of bits shown in Tables 3 and 4, the size and number 
of the LTUs may be calculated as shown in Tables 5 and 6 
below. At this point, the information bit number may be 
calculated by adding the bits remaining after multiplying the 
size of the LTU by the number of the LTU. 



TABLE 5 



35 



40 



45 



LTU Applied to Supplemental Channel (Rate Set 1} 


Transmission Rate 


LTU Size 


LTU Number 


Remaining Bits 


38400 bps 


368 bits 


2 


8 bits 


76800 bps 


376 bits 


4 


8 bits 


153600 bps 


376 bits 


8 


40 bits 


307200 bps 


760 bits 


8 


40 bits 


614400 bps 


1528 bits 


8 


40 bits 


TABLE 6 


LTU Applied to Supplemental Channel (Rate Set 2) 


Transmission Rate 


LTU Size 


LTU Number 


Remaining Bits 


57600 bps 


560 bits 


2 


8 bits 


115200 bps 


568 bits 


4 


8 bits 


230400 bps 


568 bits 


8 


40 bits 


460800 bps 


1144 bits 


8 


40 bits 


1036800 bps 


2584 bits 


8 


40 bits 



55 



60 



65 



The MuxPDU formats proposed in the invention to fill the 
information bits are shown in Tabl es 7 to 12 below. Tables 
7 and 8 show the MuxPDU formats lor the information bits 
of the fundamental channel (FCH). Tables 9 and 1 1 show the 
MuxPDU formats for the information bits of the supple- 
mental channel (SCH), for the case where the LTU is used. 
Tables 10 and 12 show the MuxPDU formats for the 
information bits of the supplemental channel, for the case 
where the LTU is not used. 



TABLE 7 



MuxPDU format for Information Bits of FCH fRate Set 1) 
Service 

1 M Service Signaling Data Service MuxPDU 
Tx Rate Data Block Message Block Identifier Header 



9600 bps 
9600 bps 
9600 bps 
9600 bps 
9600 bps 



171 bits 
80 bits 
40 bits 
16 bits 



80 bits 
128 bits 
152 bits 
168 bits 



'0' 
'0001 • 

■oior 
'ioor 

'1101' 
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TABLE 7-conlinued 



MuxPDU format for Information Bite of FCH (Rate Set 1) 



TABLE 10 



MuxPDU format for Information Bits of SCH (Rate Set 1, LTU unused) 



Service 





1" Service 


Signaling 


Data 


Service 


MuxPDU 


Tx Rate 


Data Block 


Message 


Block 


Identifier 


Header 


9600 bps 


80 bits 




85 bits 


3 bits 


•ooir 


9600 bps 


40 bits 




125 bits 


3 bits 


•our 


9600 bps 


16 bits 




149 bits 


3 bits 


'loir 


9600 bps 






165 bits 


3 bite 


'nil' 


4800 bps 


80 bits 










2700 bps 


40 bits 










1500 bps 


16 bits 











TABLE 8 



MuxPDU format for Information Bite of FCH (Rate Set 2) 



Service 





1" Service 


Signaling 


Data 


Service 


MuxPDU 


Tx Rate 


Data Block 


Message 


Block 


Identifier 


Header 


14400 bps 


266 bite 








'0* 




124 bite 


138 bits 






•00001' 




54 bits 


208 bits 






'00011' 




20 bite 


242 bite 






'00101' 






262 bite 






•ooiir 




124 bits 




135 bits 


3 bite 


•oioor 




54 bits 




205 bits 


3 bite 


'01011* 




20 bits 




239 bite 


3 bite 


'01101* 








259 bite 


3 bite 


'01111* 




20 bits 


222 bite 


17 bite 


3 bite 


4 10001* 


7200 bps 


124 bits 








'0' 




54 bite 


67 bite 






•ooor 




20 bite 


101 bite 






'0011' 






121 bite 






■oior 




54 bite 




64 bite 


3 bite 


'0111' 




20 bite 




98 bite 


3 bite 


*ioor 








118 bite 


3 bite 


•loir 




20 bite 


81 bite 


17 bite 


3 bite 


'nor 


3600 bps 


54 bite 








'0' 


20 bite 


32 bite 






'001' 






52 bite 






'Oil' 




20 bite 




29 bits 


3 bite 


'101* 








49 bits 


3 bite 


'in' 


1800 bps 


20 bits 








'0' 








17 bits 


3 bite 


'i' 



15 



30 



35 



40 



Rc- Length 
Service Length Length served of Service 
Identifier Indicator Field Field Data Block 



9600 


bps 


3 


bits 


'0' 






'000' 


max 161 bits 


9600 


bps 


3 


bits 


'V 


11 


bite 




max 153 bite 


19200 


bps 


3 


bits 


■0' 






'000' 


max 353 bite 


19200 


bps 


3 


bits 


'1' 


11 


bite 




max 345 bite 


38400 


bps 


3 


bits 


'0' 






'000' 


max 737 bite 


38400 


bps 


3 


bits 


*r 


11 


bite 




max 729 bite 


76800 


bps 


3 


bits 


'0' 






'000* 


max 1505 bite 


76800 


bps 


3 


bits 




11 


bite 




max 1497 bite 


153600 


bps 


3 


bits 


'0' 






'000' 


max 3041 bite 


153600 


bps 


3 


bits 


'1* 


11 


bite 




max 3033 bite 


307200 


bps 


3 


bits 


'0* 






'000' 


max 6113 bits 


307200 


bps 


3 


bits 


'1* 


11 


bite 




max 6105 bite 


614400 


bps 


3 


bits 


'0* 






'000' 


max 12257 bits 


614400 


bps 


3 


bits 


'1* 


11 


bite 




max 12249 bite 



TABLE 11 



MuxPDU format for Information Bits of SCH (Rate Set 2. LTU used> 











Re- 


Length 




Service 


Length 


Length 


served 


of Service 


Tx Rate 


Identifier 


Indicator 


Field 


Field 


Data Block 


28800 bps 


3 bits 


'0' 




'000' 


max 545 bits 


28800 bps 


3 bits 


'1' 


11 bite 




max 537 bits 


57600 bps 


3 bits 


'0' 




'000' 


max 537 bite 


57600 bps 


3 bits 


'1' 


11 bite 




max 529 bits 


115200 bps 


3 bits 


'0' 




'000' 


max 545 bits 


115200 bps 


3 bits 


'1* 


11 bits 




max 537 bits 


230400 bps 


3 bits 


'0' 




'000' 


max 545 bite 


230400 bps 


3 bits 


'1* 


11 bite 




max 537 bits 


460800 bps 


3 bits 


'0* 




'000' 


max 1123 bits 


460800 bps 


3 bite 


'1' 


11 bits 




max 1113 bits 


1036800 bps 


3 bits 


'0* 




'000' 


max 2561 bite 


1036800 bps 


3 bits 


'1* 


11 bits 




max 2553 bite 



TABLE 12 



MuxPDU format for Information Bite of SCH (Rate Set 2. LTU unused') 



TABLE 9 



MuxPDU format for Information Bite of SCH fRate Set 1. LTU used) 











Re- 


Length 




Service 


fj Length 


J Length 


served 


of Service 


Tx Rate \ 


Identifiery 


* Indicator , 


/ Field 


Field 


Data Block 


19200 bps 


3 bite 






'000' 


max 353 bits 


19200 bps 


3 bits 


T 


11 bite 




max 345 bits 


38400 bps 


3 bite 


'0* 




'000' 


max 345 bite 


38400 bps 


3 bite 


'1' 


11 bite 




max 337 bite 


76800 bps 


3 bite 


•0' 




'000* 


max 353 bite 


76800 bps 


3 bits 


'1' 


11 bite 




max 345 bits 


153600 bps 


3 bite 


'0' 




'000* 


max 353 bits 


153600 bps 


3 bits 


'1' 


11 bite 




max 345 bits 


307200 bps 


3 bite 


'0' 




'000* 


max 737 bits 


307200 bps 


3 bits 




11 bite 




max 729 bits 


614400 bps 


3 bite 


'0' 




'000' 


max 1505 bits 


614400 bps 


3 bits 




11 bite 




max 1497 bite 



50 



55 



60 



65 











Re- 


Length 




Service 


Length 


Length 


served 


of Service 


Tx Rate 


Identifier 


Indicator 


Field 


Field 


Data Block 


14400 bps 


3 bits 


'0' 




'000' 


max 257 bite 


14400 bps 


3 bite 


'1' 


11 bits 




max 249 bite 


28800 bps 


3 bite 


'0' 




'000* 


max 545 bite 


28800 bps 


3 bite 


'V 


11 bits 




max 537 bite 


57600 bps 


3 bits 


'0' 




'000' 


max 1121 bits 


57600 bps 


3 bite 


'1' 


11 bite 




max 1113 bits 


115200 bps 


3 bite 


'0* 




'000* 


max 2273 bite 


115200 bps 


3 bite 


'1* 


11 bite 




max 2265 bite 


230400 bps 


3 bite 


'0* 




'000* 


max 4577 bite 


230400 bps 


3 bits 


'1* 


11 bits 




max 4569 bits 


460800 bps 


3 bite 


'0* 




•000' 


max 9185 bite 


460800 bps 


3 bite 


'1* 


11 bite 




max 9177 bite 


1036800 bps 


3 bite 


'0* 




'000' 


max 20705 bite 


1036800 bps 


3 bits 


'I' 


19 bite 




max 20686 bits 



In Table 7 to 12, the service identifier can be defined as 



shown in Table 13 below. 
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TABLE 13 



14 



Service Identifier 



Service Identifier 



Service 



'000' 


Reserved 


•oor 


l rt Service 


■oio* 


2 nd Service 


'oir 


3 Id Service 


'100* 


4 111 Service 


•101* 


S m Service 


'110' 


6 m Service 


•in* 


Null Service 



In Table 13, the "null service" is a previously determined 
specific.se rvi ce idealifieL .u sed_to iSorm the multiplexin g/ 
, d_ejmiJlip1eyi Dg_conttollex. of the receiving side that the 
MuxPDUJs the fill MuxPDJU L As can be appreciated from 
Table 13, the MuxPDU formats of Tables 7 to 12 can identify 
the data blocks provided from maximum 6 services. 

Tables 7 and 8 show the MuxPDU formats transmitted to 
the fundamental channel. Here, the l sr service can be iden- 
tified depending on only th e MuxPDU header withou t (fre 
service identifier, because the case where the second lowest 
bit of the MuxPDU header is *0' corresponds to the 1 st 



10 



J5 



20 



25 



30 



35 



40 



service. The data blocks corresponding to the 2"** to 6 
services can be determined depending on the service iden- 
tifiers of Table 13. Therefore, the service identifiers of Table 
13 can have the values of '010' to '110\ When the data 
block of the 1" service is filled with all Ts in the funda- 
mental channel using the MuxPDU format of Table 7, the 
multiplexing/demultiplexing controller of the receiving side 
appoints the null traffic which does not correspond to any 
service in the multiplexing/demultiplexing controller of the 
transmission side. Therefore, when the MuxPDU received 
from the fundamental channel has only the data block of the 
I st service and the data block is filled with all l's, the 
multiplexing/demultiplexing controller of the receiving side 
decides the data block as the null traf&c. 

2. Tx Operation of Multiplexing/Demultiplexing Control- 
ler through FCH 

Assuming t hat the 6 service s using the RLP are connected, 
the multiplexing/demultiplexing controller of the transmis- 
sion side operates as follow s. This operation is performed 
according to the procedure shown i n FT*"! Q 

First, the multiplexing/demultiplexing controller 140 of 45 
FIG. 3 determines the transmitting order of the services and - 
the size of the data blocks according' to a QoS (Quality of 
Service) guarantee rule. That is, the multiplexing/ 
demultiplexing controller inquires of a signalingJLAC (Link 
"Access Control) layer about a possible^size (Step S10 of 50 
FIG. 9), and receives information abouLa proper size for tbe 
data block from the signaling LAC layer (Step Sll). The 
multiple xing/demultiplexing controller determines the order 
of transmitting the services (Step Slla), requests the 1" 
service to provide a data block of the determined size (Step 
S12), and receives the data block within the determined size 
from the 1" service (Step S13). For the data block to be 
transmitted to the fundamental channel, the RLP processor 
should be requested to generate the data block of a proper 
size according to the size and number of the data blocks that 
the MuxPDU permits in Table 7 or 8, and the Rate Set. 
Thereafter, the multiplexing/demultiplexing controller accu- 
mulates the data blocks to be transmitted and calculates the 
remaining blocks which can be transmitted (Step S14). Next, 
the multiplexing/demultiplexing controller determines 
whether or not it is possible to assemble the MuxPDU using 
the accumulated data blocks (Step SI 5). If it is not possible 



to assemble the MuxPDU, the multiplexing/demultiplexing 
controller returns to step S12 to request the corresponding 
service to provide the data block, and is provided with the 
requested data block. Otherwise, if it is possible to assemble 
the MuxPDU, the multiplexing/demultiplexing controller 
assembles the MuxPDU using the accumulated data block 
(Step S16). The multiplexing/demultiplexing controller 
selects a proper bit pattern from Table 7 or 8, and attaches 
the selected bit pattern to the MuxPDU header. The 
multiplexing/demultiplexing controller transmits the gener- 
ated MuxPDU to the physical channel in the information bits 
(Step S17). 

For the RLP processor which has failed to have an 
opportunity to generate the data block in the above process, 
the multiplexing/demultiplexing controller requests the RLP 
processor to generate a blank data block so as to enable the 
RLP processor to know the fact that it has failed to have the 
opportunity. In addition, if every RLP processor has pro- 
vided no data block in the above process, the multiplexing/ 
demultiplexing controller assembles the null traffic and 
transmits it to the physical channel in the information bits. 

3. Rx Operation of Multiplexing/Demultiplexing Control- 
ler over FCH 

The multiplexing/demultiplexing controller of the receiv- 
ing side operates as follows with respect to the information 
bits transmitted over the fundamental channel. This opera- 
tion is performed according to the procedure shown in FIG. 
10. The multiplexing/demultiplexing controller analyzes the 
transmission rate and the MuxPDU header of the received 
information (Step S20 of FIG. 10), and distinguishes the 
data blocks (Steps S21 and S22) based on the analysis. The 
distinguished data blocks are transmitted to the correspond- 
ing services based on Tables 7 and 8. If the received 
information bits are damaged, the multiplexing/ 
demultiplexing controller informs the fundamental channel 
that the damaged data block is received at all the services 
corresponding to the logical channel, and also informs the 
maximum length of the data block that the respective 
services can transmit (Step S23). Otherwise, the 
multiplexing/demultiplexing controller of the receiving side 
^ discards the data block, regarding it as the null traffic, when 
the information bits are not damaged, there exists only one 
data block and the data block corresponding to the I st 
service is filled with all 1 's. When the information bits are 
not damaged, the multiplexing/demultiplexing controller of 
the receiving side informs that a null data block is received, 
with respect to the services which have no received data 
block out of the services in which the logical channel 
corresponds to the fundamental channel. 

4. Tx Operation of Multiplexing/Demultiplexing Control- 
ler through SCH 

When generating the information bits for the supplemen- 
tal channel, the multiplexing/demultiplexing controller gen- 
erates the LTUs as many as the number shown in Table 5 or 
6 according to the transmission rate. The LTU has the size 
shown in Table 5 or 6. Since the LTU has a 16-bit CRC, the 
maximum size of the MuxPDU which can be actually 
transmitted over the LTU must accommodate the CRC. In 
the invention, for example, where the supplemental channel 
eo has a transmission rate of 307.2 Kbps and the LTU is 
generated, the maximum MuxPDU size becomes 744 bits. 

The multiplexing/demultiplexing controller generates the 
information bits of a size designated in Table 3 or 4 
according to the transmission rate, if the LTU is not gener- 
65 ated when the information bits for the supplemental channel 
are generated. The multiple xing/demultiplexing controller 
determines the order of transmitting the services and the size 
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of the data blocks according to the QoS guarantee rule. Next, data. In the invention, at least one of the multiplex frames is 

the multiplexing/demultiplexing controller sends a data comprised of a plurality of sub -multiplex frames, and each 

block request to the RLPof the respective services according sub-multiplex frame is comprised of a header including an 

to the priority order (Step S30 of FIG. 11). For the data block RLP service identifier field and a length indicator field for 

to be transmitted to the supplemental channel, the 5 indicating a length of the transmission data, and a succeed- 

multiplexing/demultiplexing controller requests the RLP mg data block. That is, the multiplex frame can be either one 

processor to generate the data block of a proper size accord- sub-multiplex frame comprised of a data block for a certain 

ing to the size of the data block, permissible by the LTU in an ? a ^ukr indicating the data block or a plurality 

Table 5 and the remaining period of the LTU being presently of sub-multiplex frames each comprised of a data block for 

enerated CSte s S32 to S37) 10 a semce anc * a Qeacier indicating the data block. FIG. 6A 

* n A e c P jr tli r t.l nm shows a case where the multiplex frame is comprised of one 

As can be appreciated from Table 5, if the RLP processor su5 . multi lex frarae> { the P multi plex frame includes only 

generates the data block .of 737 bits or generates a data block Qne daU ^ F[G 6B shows a £ se whefe ^ mm ] £ 

having a size proper to fill the remaining period of the LTU, frame is compriscd of a plurality of sub-multiplex frames, 

the multiplexing/demultiplexing controller sets the service [x > the mult j p iex frame includes a plurality of data blocks. 

' identifier to the corresponding service and sets the length 15 An operation of generating the data block (or RLP frame) is 

indicator to '0\ Further, the multiplexing/demultiplexing performed by the RLP controller 131 of FIG. 3, and an 

controller attaches a 3-bit reversed field and arranges the operation of generating the multiplex frame is performed by 

data block, thereby generating the MuxPDU. Since the the multiplexing/demultiplexing controller 140 of FIG. 3. 

generated MuxPDU fits into the payload of the LTU, one Further, an operation of generating the information frame (or 

LTU is completed by generating a CRC and attaching the 20 physical frame) is performed by the physical layer processor 

generated CRC to the MuxPDU. ' 150 of FIG. 2. 

As can be understood from Table 5, if the RLP generates Referring to FIG. 6 A, a first LTU is provided with a 

the data block having a length of 729 bits or below and it is 737-bit data block from the first service. In this case, the 

not possible to fill the remaining period of the LTU with the service identifier is set to <001\ the length indicator is set to 

generated data block, the multiplexing/demultiplexing con- 25 <0 ' aild tbe payload of the LTU is filled with 3 reserved bits 

trailer sets the service identifier to the corresponding service '° 00 '' Hcre » the scrvicc .identifier, the length indicator and 

and sets the length indicator to '1'. The multiplexing/ * e res t? ed blts ^nsUtute the header of the multiplex 

demultiplexing controller sets the 11-bit length field of the frame " ™ e t *™?.^ nt £ cr - T mdlcates k that ^ ™?" 

. * i ** nrMi ■ i j- *u • j 4 % ti _ , ceeding data block is for the first service as shown in Table 

total MuxPDU including me service identifier, the length ^length indicator Vindicates that the multiplex frame 

indicator me length field and the data block to a value 30 £ Qnc data b]ock ^ ^ 3 _ bh fieJd 

expressed m byte unit. When the size of the total MuxPDU ^ { h q{ ^ data block M sh()wn in 

is not expressed in the byte unit, the multiplexing/ Xables 9 to 12 For examplej with refe rence to Table 9, 

demultiplexing controller dtscards the data block. assuming that the LTU is used at the Rate Set 1 and the 

The above process is repeated for the period remaining transmission rate is 307200 bps, if the multiplex frame is 

after filling the generated MuxPDU in the payload of the 35 comprised of only one service data block, then the length 

LTU. If it is not possible to fill the remaining period with the indicator is '0' and the reversed field is '000'. Therefore, the 

valid MuxPDU, the multiplexing/demultiplexing controller length of the service data block becomes maximum 737 bits, 

fills the remaining period with all 0's. If there is no data Referring to FIG. 6B, a second LTU is provided with a 

block of proper size although it is possible to fill the 329-bit data block from the second service. In this case, the 

remaining period with the valid MuxPDU, the multiplexing/ 40 service identifier is set to '010*, the length indicator is set to 

demultiplexing controller creates a data block having a size *V and the length field is set to 43 bytes (00000101011) 

proper to fill the remaining period and fills the data block which is the total length of the MuxPDU. The remaining 

with all 0's, and thereafter creates the MuxPDU, in which 50-byte payload period of the LTU is filled with the fill 

the service identifier is set to '111' and the length indicator MuxPDU, when no service data block is provided. Here, the 

is set to '0' and the 3-bit reversed field is set, and then fills 45 service identifier, the length indicator and the length field 

the payload. A CRC is generated and attached to the gen- constitute the header of the multiples firame. The LTU, i.e., 

erated payload for the LTU, thereby completing the LTU. the multiplex frame is comprised of 2 sub-multiplex frames. 

When it is necessary to generate 8 LTUs in the above In the first sub -multiplex frame, the service identifier '010' 

process, the multiplexing/demultiplexing controller sequen- indicates that the succeeding data block is for the second 

ti ally puts the generated 8 LTUs all in the information bits. 50 service as shown in Table 13, the length indicator T 

The multiplexing/demultiplexing controller fills the remain- indicates that the multiplex frame includes another data 

ing 40-bit period, shown in Table 5, with all 0's. An example block in addition to the data block for the second service, 

of the information bits which can be obtained in this process and the 11-bit length field indicates the length of the service 

is shown in FIGS. 6A to 6C. data block as shown in Tables 9 to 12. That is, the length 

FIGS. 6 A to 6C show several formats of the LTU gener- 55 indicator and the length field constitute a length indication 

ated according to the invention. Such LTUs constitute an field including information for indicating a length of the data 

information frame to be transmitted over the physical to be transmitted. 

channel, and each LTU is comprised of the multiplex frame In the second sub-multiplex frame, the service identifier 

MuxPDU and the CRC. Although FIGS. 6A to 6C show an '111' indicates that the succeeding data block is for th e null 

example where the information frame is comprised of the 60 service as shown in Table 13, the length indicator '0' 

LTUs, the information frame may be comprised of only the indicates that the multiplex frame includes no data block in 

multiplex frames MuxPDUs without the CRC. The consecu- addition to the data block for the null service, and the 3-bit 

tive multiplex frames MuxPDUs included in the information reserved field indicates the length of the service data block 

frame may have a given length (e.g., 744 bits as shown in as shown in Tables 9 to 12. That is, the length indicator and 

FIG. 5C), and each multiplex frame MuxPDU is comprised 65 the reserved field constitute a length indication field includ- 

of a header and a succeeding RLP frame (or data block) as ing information for indicating a length of the data to be 

shown in FIG. 5B. The RLP frame includes transmission transmitted. 
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Referring to FIG. 6C, a third LTU is provided with no data 
block from the services. In this case, the LTU is filled with 
the fill MuxPDU. The 8 LTUs shown in FIGS. 6Ato 6C are 
filled in the information bits and the remaining 40 bits are set 
to '()', thus completing generation of the information bits (or 
information frame). 

5. Rx Operation of Multiplexing/Demultiplexing Control- 
ler over SCH 

The multiple xing/demultiplexing controller of the receiv- 
ing side operates as follows for the information bits trans- 
mitted over the supplemental channel. 

For the information bits using the LTU, the LTU is divided 
according to the transmission rate as shown in FIGS. 5A to 
5C. In the embodiment of the present invention, for 
example, the supplemental channel is assumed to have a 
transmission rate of 307.2 Kbps, so that the LTU is divided 
by 760 bits. If the information bits have no error, the 
multiplexing/demultiplexing controller separates the Mux- 
PDU from each LTU (Step S40 of FIG. 12). Otherwise, if the 
information bits have errors, the multiplexing/ 
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15 



In FIG. 7, an A- type data block is used when the funda- 
mental channel transmits data at the transmission rate of 
below 9.6 Kbps or 14.4 Kbps, and has an information field 
only. The A-type data block fits into the data block size 
specified in Table 7 or 8. That is, when the A-type data block 
does not completely fill the specified data block size, the 
RLP controller 131 fills the data block with 0's so as to fit 
the data block into the specified data block size. 

In FIG. 7, the B and C-type data blocks may be used when 
the fundamental channel transmits data at the transmission 
rate of 9.6 Kbps or 14.4 Kbps, or may be used for the 
supplemental channel. The B and C-type data blocks may be 
identified depending on the TYPE field. That is, the TYPE 
field ( 0' indicates the B-type data block, and the TYPE field 
'V indicates the C-type data block. 

-The B-type data block is comprised of a 1-bit TYPE field 
and an INFORMATION field. In particular, for the funda- 
mental channel, the B-type data block has the INFORMA- 
TION field of fixed length. That is, when the B-type data 



demultiplexing controller performs CRC checking on each 20 block is used for the fundamental channel, it is necessary to 



LTU, At this point, the multiplexing/demultiplexing control- 
ler separates the MuxPDU for the error-free LTUs. However, 
for the LTUs having errors, the multiplexing/demultiplexing 
controller informs all the services, in which the logical 
channel corresponds to the supplemental channel, that a 25 
damaged data block is received, and also informs the maxi- 
mum length of the data block that the respective services can 
transmit to the LTU, and then discards the information bits. 

For the information bits not using the LTU, the MuxPDU 
are separated over the whole information bits. If the infor- 30 
mation bits have errors, the multiplexing/demultiplexing 
controller informs all the services, in which the logical 
channel corresponds to the supplemental channel, that a 
damaged data block is received, and also informs the maxi- 
mum length of the data block that the respective services can 35 
transmit to the LTU, and then discards the information bits. 

When separating the MuxPDUs over the LTU or infor- 
mation bits, which service the data block that the MuxPDU 
has been transmitted over and the total length of the Mux- 



generate the INFORMATION field of 170 bits or 265 bits. 
However, when transmitting the B-type data block over the 
supplemental channel, such a limitation is not required. 

The C-type data block is comprised of a 1-bit TYPE field, 
a 16-bit SEQ field and a DATA field having a length which 
is a multiple of 8. In particular, for the fundamental channel, 
the C-type data block has the DATA field of a fixed length. 
That is, when transmitting the C-type data block over the 
fundamental channel, it is necessary to fill the DATA field 
with 152 bits or 248 bits. However, when transmitting the 
C-type data block over the supplemental channel, such a 
limitation is not required. 

The INFORMATION field defined in the A and B-type 
data blocks is shown in FIG. 8. Referring to FIG. 8, the 
INFORMATION field may include several RLP frames and 
the remaining period (portion) is filled with 0's, when the 
size of the INFORMATION field is not 16 bits, 17 bits, 20 
bits or 29 bits. When the size of the INFORMATION field 
is 1 6 bits, 17 bits, 20 bits or 29 bits, the RLP frame includes 



PDU are known from the service identifier, the length 40 the idle frame shown in FIG. 8. The idle frame of FIG. 8 



indicator and the length field. Therefore, the multiplexing/ 
demultiplexing controller of the receiving side separates the 
MuxPDUs according to the length information of the 
MuxPDU, beginning at the front of the LTU or information 
bits, and transmits the data block to the upper service 
according to the service identifier. If the service identifier is 
set to '111' or the remaining period of the LTU or informa- 
tion bits is not long enough to put the valid MuxPDU 
therein, the multiplexing/demultiplexing controller discards 
all the remaining period of the LTU or information bits. 
C Tx/Rx Operation of RLP Controller According to the 
Invention 

Operation performed by the RLP controller 131 shown in 
FIGS. 3 and 4 will be divided as follows. 

1. Operation of RLP Controller before Data Transmission 
Before starting operation, the RLP controller 131 initial- 
izes the L_V(S) register 132, the L_V(N) register 135, the 
L__V(R) register 136 and the E register 134, shown in FIGS. 
3 and 4, to '0\ Before starting operation, the RLP controller 
131 empties the forward resequencing buffer 133, the NAK 
list 137 and the rearrange buffer 138. Finally, the RLP 
controller 131 deactivates all the retransmission-related tim- 
ers. 

The types of the data blocks that the RLP controller 131 
can transmit to the multiplexing/demultiplexing controller 
are shown in FIG. 7. FIG. 7 shows three types of the data 
blocks, by way of example. 
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includes 16-bit SEQ field, and the remaining period is filled 
with all 0's. 

In the invention, the RLP frame of FIG. 8 will be called 
as follows. The SYNC, SYNC/ACK, ACK or NAK frame 
shown in FIG. 8 and Table 14 below will be referred to as 
a "control frame" and the frame filled with data will be 
referred to as a "data frame". The data frame is divided into 
a new data frame which contains new transmission data of 
at least one byte, and a retransmitted data frame which 
contains the retransmission data only. A frame having the 
16-bit SEQ field only will be referred to as an idle frame, 
separately from the control frame and the data frame. 

The INFORMATION field of FIG. 8 can include only one 
control frame; include one new data frame, 0's or several 
retransmitted data frames; or include only one idle frame. 

When received a data block which does not satisfy the 
above conditions, the RLP controller 131 considers the 
received data block as a damaged (or bad) data block. 

Prior to data transmission, the RLP controller 131 per- 
forms a reestablishing process. The RLP controller 131 
continuously transmits the SYNC frame for the data block to 
the multiplexing/demultiplexing controller 140. Upon 
receipt of the SYNC frame from the multiplexing/ 
demultiplexing controller 140, the RLP controller 131 con- 
tinuously transmits the SYNC/ACK frame to the 
multiplexing/demultiplexing controller 140 until a physical 
channel frame is received which is neither a null data block 
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nor a SYNC frame. Upon receipt of the SYNC/ACK frame, 
the RLP controller 131 transmits an ACK frame to the 
multiplexing/demultiplexing controller 140. The RLP con- 
troller 131 continuously transmits the ACK frame, until the 
physical channel frame received from the multiplexing/ 
demultiplexing controller 140 is neither the null data block 
nor the SYNC/ACK frame. The RLP controller 131 starts 
data transmission, when the physical channel frame is 
received and the received data block is not the null data 
block and has the RLP frame which is not the SYNC/ACK 
frame. Upon receipt of the ACK frame, the RLP controller 
131 starts data transmission. The RLP controller 131 can 
transmit the frames other than the SYNC, SYNC/ACK and 
ACK frames to the multiplexing/demultiplexing controller 15 
140. 

2. Data Transmitting Operation of RLP controller 
For data transmission, the RLP controller 131 uses the 
21 -bit sequence number register L__V(S) 132. The RLP 20 
controller 131 determines a sequence number SEQ to be 
attached to the frame in the sequence number register 
L_V(S) 132. The sequence number uses a signless modulo 
operation with 2 21 . For a sequence number N, it is said that 
the sequence numbers from (N+l) modulo 2 21 to (N+2 20 +l) 
modulo 2 21 is larger than N, and the sequence numbers from 
(N-2 20 ) modulo 2 21 to (N-l) modulo 2 21 is smaller than N. 
The RLP controller 131 can use the value stored in the 



For the NAK frame, the RLP controller 131 uses the 
structure shown in Table 14 below. 

TABLE 14 



NAK frame 



Field 



Length 



NAK_COUNT 



8 bits 
2 bits 



The next fields are filled as many times as NAK_COUNT + 1 



NAK_TYFE_AND_UN1T 
When NAK_TYPE_AND_UNIT is '00Q1V 



4 bits 

the next fields are filled 



FIRST 21 bits 
LAST 21 bits 
When NAK_TYPE_AND_UN1T is a value defined in Table 15 oi 
16, the next fields are filled 

NAK_MAP_SEQ 21 bits 

NAK_MAP 8 bits 

The next fields are field for any NAK_TYFE 



FADDING_1 
FCS 

PADDING_J2 



Variable Length 

16 bits 
Variable Length 



The RLP controller 131 creates the NAK frame as shown 
in Table 14. The CTL field of Table 14 is set to '11100100'. 
The RLP controller 131 sets the NAK__COUNT field to a 
value obtained by subtracting one from the retransmission 



request number included in the NAK frame. The RLP 
sequence number register L_V(S) 132 or a low bit value of 30 controller 131 performs the (NAK_COUNT+l) retransmis- 
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the stored value for a physical sequence number to be 
attached to the actual data. That is, in the data frame, the 
lower 16 bits or all the lower 21 bits are used for the physical 
sequence number and in the idle frame, the lower 16 bits are 
used for the physical sequence number. The sequence num- 
ber register L_V(S) 132 increases as much as the number of 
the filled data bits, when a data frame is created in which the 
data to be first transmitted is filled. That is, when the data 
frame is filled with the previously transmitted data, the 
L__V(S) register 132 is not increased. 

The RLP controller 131 attaches a unique 21 -bit sequence 
number every data byte of the new data frame from the 
L__V(S) register 132. That is, if L_V(S) is S to transmit 
N-byte data, then the first byte of the data has a sequence 
number of S, the nth byte has a sequence number of (S+n-1) 
modulo 2 21 , the last Nth byte has a sequence number of 
(S+N-1) modulo 2 21 . After transmitting the N-byte new 
data, the RLP controller 131 sets the L_V(S) register to 
(S+N) modulo 2 21 . 

The RLP controller 131 stores the newly transmitted data 
in the forward resequencing buffer 133 together with the 
sequence number, preparing for the retransmission request 
from the receiving side. Upon receipt of a transmission ss 
request from the receiving side, the RLP controller 131 reads 
the data byte corresponding to the requested sequence 
number from the forward resequencing buffer 133 and 
retransmits the read data. 

The RLP controller 131 assembles a frame to be 
transmitted, as follows. For the SYNC, SYNC/ACK, and 
ACK frames, the RLP controller 131 sets a CTL field 
according to the frame type and then attaches an FCS field, 
as shown in FIG. 8. The FCS field is a 16-bit frame check 
sequence created by a polynomial specified by RFC-1662. 
This FCS field is created for all the preceding bits. 



sion requests. The RLP controller 131 may perform the 
retransmission requests as follows. 

When the NAK_TYPE _AND_UN1T field of the trans- 
mission request is set to '0001', the RLP controller puts the 
first sequence number of the consecutive retransmission 
requests in the FIRST field, and puts the last sequence 
number to the LAST field. 

The RLP controller 131 may set the NAJL_TYPE_ 
AND__UNIT field as shown in Table 15 or 16 below. When 
the NAK_TYPE_AND_UNIT field is set as shown in 
Table 15 or 16, the RLP controller 131 performs retrans- 
mission request in NAK_MAP method. Here, the NAK_ 
MAP method refers to requesting retransmission using a 
NAK_MAP_SEQ field and a NAK_MAP field. 

TABLE 15 



50 



NAK_TYFE_AND 


_UNIT field fRate Set 1) 


Field Value 


Number of Sequence Number 


'0010' 


19 


4 0011 ' 


41 


'0100' 


42 


•oior 


90 


'0110' 


186 


•our 


378 


•1000' 


762 


•100T 


1530 


'loio'-'inr 


Reserved 
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TABLE 16 



NAKJYPE^AND UNIT field (Rate Set 2) 
Field Value Number of Sequence Number 



'000 V 
'0010' 



31 
65 
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TABLE 16-continued 



22 



NAK_TYPE _AND_UNIT field fRate Set 2) 



Field Value 



Number of Sequence Number 



'ooir 


66 


'0100' 


138 


•oioi* 


318 


•0110' 


282 


■our 


570 


'1000' 


1146 


•ioor 


2586 


•loio'-'inr 


Reserved 



The RLP controller 131 fills the NAKJMAP field and 
NAie_MAP_SEQ field based on Table 15 or 16. The first 
sequence number is filled in the NAK__MAP_SEQ field, 
and the sequence numbers for requesting retransmission in 
the unit shown in Table 15 or 1 6 are filled in the NAK__MAP 
field. By using the NAK_MAP, the RLP controller 131 
requests retransmission for the data corresponding to the 
sequence number belonging to (NAK_MAP_SEQ+U-1) 
modulo 2 21 , when the unit determined by the NAK_ 
TYPE_AND_UNIT field is U; and requests retransmission 
for the data corresponding to the sequence number belong- 
ing to (NAK_MAP SEQ+n*U) modulo 2 21 to (NAK_ 
MAP_SEQ+(n+l)*U-l) modulo 2 21 whenever an nth bit 
from the most significant bit (MSB) of the NAK_MAP field 
is T. The value 'n* can have a value of 1 to 8. 

For example, if the NAK_J^AP_SEQ field is set to '0' 
and NAK_MAP field is ' 10000000' for the NAK_TYPE__ 
AND_UNIT neld='0010' and the Rate Set 1, the RLP 
controller retransmits the data corresponding to the sequence 
number of 0 to 37, upon receipt of the information. 

The RLP controller 131 puts the (NAK_COUNT+l) 
transmission requests in the NAK frame, pads the FCS field 
with O's for byte alignment and then fills the FCS field. The 
FCS field is a 16-bit frame check sequence created by the 
polynomial specified in the RFC-1662. The FCS field is 
created for all the preceding bits. After filling the FCS field, 
the RLP controller 131 fills the remaining period of the data 
block with O's. 

When transmitting the data, the RLP controller 131 may 
use the variable-length data frame shown in FIG. 8. When 
the data included in the variable-length data frame is new 
transmission data, the RLP controller 131 sets the SEQ field 
with the lower 16 or 21 bits of the L_V(S) register, and 
properly sets the CTL field as shown FIG. 8. A LEN field of 
the variable-length data frame indicates a length of the data 
period in a byte unit. The RLP controller 131 fills the period 
remaining after data filling, with O's. 

If it is determined that the lower 16 bits of the sequence 
number are sufficient for the SEQ field, the RLP controller 
131 uses the 16-bit SEQ field of FIG. 8. However, where it 
is determined that all the 21 bits of the sequence number 
should be used due to great damage of the data, the RLP 
controller 131 uses the 21 -bit SEQ field of FIG. 8. 

The RLP controller 131 uses the shortest one, which can 
indicate the data length, out of the 5-bit, 13-bit, 8-bit and 
16-bit LEN fields. 

When the data included in the variable-length data frame 
is the retransmission data, the RLP controller 131 sets the 
SEQ field with the lower 16 or 21 bits of the sequence 
number S for the first byte, and properly sets the CTL field 
as shown FIG. 8. The LEN field indicates a length of the data 
period in a byte unit. The RLP controller 131 fills the 
remaining period of the data block with 0*s. 

When the CTL field is '100' in the variable-length data 
frame to be transmitted over the fundamental channel, for 



example, the RLP controller 131 fills the data block with 
144-bit data for the Rate Set 1 and 240-bit data for the Rate 
Set 2. 

If there is no data to transmit or there are no SYNC, 
5 SYNC/ACK, ACK and NAK frames to transmit, the RLP 
controller 131 may transmit the data block in which the SEQ 
field of the variable-length data frame is set with the lower 
16 or 21 bits of the L_V(S), the LEN field is set to *0\ and 
the remaining period is filled with 0 J s. In this case, the CTL 
10 field is set to a proper value. 

If the multiplexing/demultiplexing controller 140 requests 
a data block having a length of 16 bits, 20 bits or 32 bits, or 
there is no data to transmit or there are no SYNC, SYNC/ 
ACK, ACK and NAK frames to transmit, then the RLP 
15 controller 131 may transmit the idle frame shown in FIG. 8. 
To create the idle frame, the RLP controller 131 fills the SEQ 
field with the lower 16 bits of the L__V((S). The RLP 
controller 131 fills the remaining period of the data block 
with O's. 

3. Data Receiving Operation of RLP Controller 
When receiving data, the RLP controller 131 uses the 
L_V(N) 135 and the L_V(R) 136, which are 21 -bit 
sequence number registers. The sequence number register 
L_V(R) 136 indicates the sequence number of the new data 
byte to be received next, and the sequence number register 
L_V(N) 135 indicates the sequence number of a data byte 
to be received next, out of the consecutively received data 
bytes. That is, the RLP controller 131 may transmit the data 
to the upper link protocol only when the data byte having the 
sequence number stored in the L_V(N) arrives. A data byte 
having the sequence number larger than or equal to L__V(R) 
is new data, whereas a data byte having a sequence number 
smaller than L__V(R) and larger than or equal to L_V(N) is 
retransmission data. The RLP controller 131 cannot discard 
the data byte having the sequence number smaller than 
L_V(N), because it is the previously received data. 

The RLP controller 131 typically has the NAK list 137 
shown in FIG. 4. Each entry of the NAK list 137 has a 21 -bit 
sequence number and a data byte corresponding to the 
sequence number, and also has a retransmission timer and an 
abort timer. When the retransmission data arrives, the RLP 
controller 131 delects an entry where the 16-bit sequence 
number for the received data byte is consistent with the 
lower 16 -bit of the stored NAK entry. 

If the received data-filled frame includes the 16 -bit SEQ 
field, the RLP controller 131 takes this value for S and 
calculates a sequence number L__SEQ for the first byte of 
the received data, as follows. That is, the RLP controller 131 
detects the entries having consistent sequence numbers from 
the NAK list 137 in the order of older entries. The RLP 
controller 131 determines whether the NAK list 137 has an 
entry where the lower 16-bit period of the 21 -bit sequence 
number is consistent with the sequence number S of the 
received frame. If there is a consistent NAK entry, the RLP 
controller 131 takes the 21 -bit sequence number stored in 
the entry as the sequence number L SEQ of the first byte. 
Otherwise, if there is no NAK entry, the RLP controller 131 
calculates the sequence number L_SEQ for the first byte of 
the received data using the sequence number S of the 
received frame, in accordance with Equation 1 below. 

i_SEQ-{L_V(A0+[2 1<5 +5- J L_V{A0] modulo 2 16 } modulo 2^Eq.l) 

If the received data-filled frame includes the 21 -bit SEQ 
field, the RLP controller 131 takes this value for L_SEQ. 

The RLP controller 131 sequentially attaches the 
sequence numbers for the respective data bytes of the 
received data frame, which start from L__SEQ. That is, an 
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nth data byte has a sequence number L«(L_SEQ+n-l), and 
thus, the first byte takes the L__SEQ value for the sequence 
number. The RLP controller 131 performs the following 
operation on the data bytes of the received data frame in the 
order of the sequence numbers. 

First, if the sequence number, L, of the received data byte 
is smaller than L_V(N), the RLP controller 131 discards the 
received data byte. 

Second, if the sequence number, L, of the received data 
byte is larger than or equal to L_V(N) and smaller than 
L__V(R), the RLP controller 131 stores the received data 
byte in the rearrange buffer 138. At this point, if the 
sequence number L«L_JV(N), the RLP controller 131 trans- 
mits the data bytes stored in the rearrange buffer 138 to the 
upper link protocol, from the data byte having the sequence 
number L_V(N) to the data byte having the sequence 
number which can be successively transmitted. In this 
process, if the sequence number of the last transmitted data 
byte is LAST, the RLP controller 131 sets L_V(N) to 
(LAST+1) modulo 2 21 . 

Third, if the sequence number, L, of the received data byte 
is equal to L_V(R) and L_V(R) is equal to L_V(N), the 
RLP controller 131 increases both L__V(R) and L_V(N), 
and then performs modulo operation for 2 21 . Otherwise, if 
L_V(R) is not equal to L_V(N), the RLP controller 131 
transmits the received data byte to the upper link protocol, 
increases L_V(R) and then performs modulo operation for 
2 2 \ The RLP controller 131 stores the received data byte in 
the rearrange buffer 138. 

Fourth, if the sequence number, L, of the received data 
byte is larger than L_V(R), the RLP controller 131 creates 
an entry for each data byte in the NAK list 137 in order to 
request retransmission for the data byte having (L-l) 
modulo 2 21 in the sequence number L__V(R). Each entry has 
a 21 -bit sequence number for the corresponding data byte. In 
addition, the RLP controller 131 stores the received data 
bytes in the rearrange buffer 138 and then sets L__V(R) to 
(L+l) modulo 2 21 . 

Meanwhile, upon receipt of the idle frame, the RLP 
controller 131 sets the sequence number S to the SEQ field 
value and then calculates the sequence number L_SEQ in 
accordance with Equation 2 below. 

L_SEQ^{L_V{R)+{1 11S +S-L_V(R)] modulo 2 1<s } modulo 2tEq. 2) 

If the sequence number, L SEQ, of the received idle frame 
is larger than L_V(R), the RLP controller 131 creates an 45 
entry for each data byte in the NAK list in order to request 
retransmission for the data byte having (L_SEQ-1) modulo 
2 21 in the sequence number L_V(R). Each entry has a 21 -bit 
sequence number for the corresponding data byte. The RLP 
controller sets L__V(R) to (L+l) modulo 2 21 . 

When the multiplexing/demultiplexing controller 140 
informs that the damaged data block is received and informs 
the size of the data block, the RLP controller 131 predicts the 
maximum value, M, of the data byte which can be received, 
as follows. If the damaged data block was transmitted over 
the fundamental channel and the Rate Set 1 is being used, 
then M is 19 bytes. If the damaged data block was trans- 
mitted over the fundamental channel and the Rate Set 2 is 
being used, M is 31 bytes. Otherwise, if the damaged data 
block was transmitted over the supplemental channel, then 
M is a value determined by dividing, by 8, a value obtained 
by subtracting 17 bits from the L-bit length of the damaged 
data block informed by the multiplexing/demultiplexing 
controller 140. For example, if the informed length of the 
damaged data block is 737 bits, then M=(737-17)/8«90. 

After determining the maximum data byte number, M, of 
the damaged data block, the RLP controller 131 adds this 
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value to the value stored in the register E 134 and then stores 
it again in the register E 134. If the added value is larger than 
2 16 t the RLP controller 131 performs the above reestablish- 
ing process. 

In the data receiving process, if there exists at least one 
correctly received data block which is not the null data block 
or if the multiplexing/demultiplexing controller informs that 
no frame has been received, the RLP controller 131 sets the 
register E 134 to *0\ 

4. Operation of RLP Controller after Data Receiving 

After processing all the received frame, the RLP control- 
ler 131 performs the following operation. When the 
multiplexing/demultiplexing controller 140 informs the RLP 
controller 131 that no frame has been received, or when an 
idle frame is received or a new transmitted data frame is 
received, the RLP controller 131 performs the following 
processes on the entries in the NAK list 137 in the order of 
the older entries. 

First, if an abort timer has not expired yet and the 
sequence number, included in the NAK has been transmitted 
three times, the RLP controller 131 decreases the abort timer 
value by one. If the abort timer value becomes '()', the RLP 
controller 131 performs the following operation. If the RLP 
controller 131 has received the retransmitted data byte 
corresponding to the sequence number that the NAK entry 
already has, the RLP controller 131 deletes the NAK entry. 
Otherwise, if the RLP controller 131 has not received the 
retransmitted data byte corresponding to the sequence num- 
ber that the NAK entry already has, the RLP controller 131 
transmits to the upper link protocol the received data bytes 
which are larger than the sequence number of the NAK list 
stored in the rearrange buffer 138 and can be successively 
transmitted to the upper link protocol, considering that the 
data byte corresponding to the sequence number of the NAK 
entry is not received. The RLP controller 131 sets L„V(N) 
to the sequence number of the data byte to be received next. 

Second, if the abort timer has not expired yet and the 
sequence number, that the NAK entry has, was included in 
the NAK which has already transmitted two times, the RLP 
controller 131 decreases the abort timer value by one. If the 
abort timer value becomes '0', the RLP controller 131 
performs the following operation. If the RLP controller 131 
has received the retransmitted data byte corresponding to the 
sequence number that the NAK entry already has, the RLP 
controller 131 deletes the NAK entry. Otherwise, if the RLP 
controller 131 has not received the retransmitted data byte 
corresponding to the sequence number that the NAK entry 
already has, the RLP controller 131 sets the abort timer of 
the NAK entry to a proper value. The RLP controller 131 
includes the sequence numbers, that the NAK entry has, in 
the three NAK frames to be transmitted next. 

The RLP controller 131 sets the retransmission timer to a 
proper value for the NAK entries which should be newly 
added, and includes the sequence numbers, that the NAK 
entry has, in the two NAK frames to be transmitted next. 

As described above, the invention provides a data byte- 
based sequence number when transmitting data according to 
a radio link protocol (RLP), thereby enabling the radio link 
protocol to generate the variable-length frame. 

While the invention has been shown and described with 
reference to a certain preferred embodiment thereof, it will 
be understood by those skilled in the art that various changes 
in form and details may be made therein without departing 
from the spirit and scope of the invention as defined by the 
appended claims. 
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What is claimed is: 

1. An information frame comprised of a plurality of 
consecutive multiplex frames_ each having a given length, 
each multiplex frame comprised of a header and a succeed- 
ing radio link protocol (RLF) frame , said RLP frame includ- 
ing a transmission data , wherein afleast one of the multiplex 
frames is comprised of a plurality of sub-multiplex frames . 
and eacti sub - multip lex frame is comprised of a heade r 
i ncluding a RLP service identifier and a length indication 
"field for indicating a length of the transmission data, anda 
dat a block associated jfti lhJh^ufcccEdingJ . 
"*2. The information frame as claimed in claim 1, wherein 
the length indication field is comprised of a length indicator 
for indicating whether there exists one succeeding RLP data 
block, and a length field for indicating a length of the 
succeeding RLP data block. 

3. The information frame as claimed in claim 1, wherein 
the length indication field is comprised of a length indicator 
for indicating whether there exists one succeeding RLP data 
block, and a reserved field for indicating a length of the 
succeeding RLP data block. 

4. An information frame comprised of a plurality of 
consecutive multiplex frames each having a given length, 
each multiplex frame comprised of a header and a succeed- 
ing radio link protocol (RLP) frame, said RLP frame includ- 
ing a transmission data, wherein the multiplex frames are 
each comprised of a header including a RLP service iden- 
tifier and a length indication field for indicating a length of 
the transmission data, and a data block associated with the 
succeeding RLP frame. 

5. A method for transmitting frames in a mobile commu- 
nication system which transmits frames for several services, 
the method comprising the steps of: 

creating a multiplex frame of a given length including at 
least one of the RLP frame determined according to a 
service priority, the RLP frame including a header 
comprised of a RLP service identifier indicating a 
service of the RLP frame and a length indicator indi- 
cating a length of the RLP frame; and 
^assembling a plurality of the consecutive multiplex 



frames into an information frame of a predetermined 
length and transmitting the information frame. 
6. A data transmission device in a mobile communication 
system comprising: 

a plurality of RLP p rocessors each for processing unique 
' service data and generating a RLP frame of a prede- 
termined length; 
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a multiplexing controller for determining a length of the 
RLP frame generated from the RLP processors, and 
assembling a multiplex frame having a first length 
including at least one RLP frame generated from the 
5 RLP processors, includin g^ header comprised of a 
service identifier in dicating a service of the RLP frame 
and a length indicator indicating a length of the RLP 
frame; and 

io a physical layer processor for assembling a plurality of the 
consecutive multiplex frames into an information 
frame of a second length and transmitting the informa- 
tion frame. 

7. A method f orjeceiving frames in a mobile communi- 
1 5 cation system which receives an information frame com- 

prised of a plurality of consecutive multiplex frames, each 
multiplex frame including at least one RLP frame, at the 
head of which a header is attached which is comprised of a 
2 0 service identifier indicating a service of the RLP frame and 
a length indicator indicating a length of the RLP frame, the 
method comprising the steps ofc, 
demultiplexing the multiplex frame included in the 

received information frame; and 
separating at least one RLP frame included in a demul- 
tiplexed frame according to the services using the 
length indicator of the header, and outputting the sepa- 
rated RLP frame to the corresponding service for 
processing. 

8, A device for receiving frames in a mobile communi- 
cation system which receives an information frame com- 
prised of a plurality of consecutive multiplex frames, said 
each multiplex frame including at least one RLP frame, at 
the head of which a header is attached which is comprised 
of a service identifier indicating a service of the RLP frame 
and a length indicator indicating a length of the RLP frame, 
the device comprising: 

a demultiplexing controller for separating at least one 
RLP frame included in the multiplex frame in the 
received information frame according to the services 
using the length indicator of the header; and 
a plurality of RLP processors for performing a corre- 
sponding service on the separated RLP frame. 
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